Add Book to My BookshelfPurchase This Book Online

Chapter 6 - Supporting Popular WAN Technologies

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Point-to-Point Protocols
In this section we look briefly at the older Serial Line Interface Protocol (SLIP), the newer Point-to-Point Protocol (PPP) that largely replaced it, and give an overview of HDLC. These protocols all provide connectivity in point-to-point connections; they do not provide multipoint communication, as does frame relay, or full routing functionality, as does X.25.
SLIP Communications
SLIP, as its name suggests, supports point-to-point communication for IP only. It was the first point-to-point protocol to do so for asynchronous connections and still has widespread support from many Unix vendors. The SLIP frame is very simple: There is no header, no error checking, and no option to define a protocol. (It is always assumed that IP is the higher-layer protocol.) SLIP is mainly used for asynchronous dial-up connections. Even for this limited application, SLIP is generally found wanting these days; there is no authentication process available, for example, which is a common requirement for security-minded organizations implementing a dial-up facility.
SLIP works only on asynchronous lines, and does not support address negotiation as part of the link startup procedure. The only time you are likely to need to use SLIP is when connecting to a third party's Unix machine via dial-up. Any new dial-up facilities being implemented should use PPP. In this instance, you will be provided with an IP address by the third-party administrator to use for the dial-up connection. The following is a simple configuration for an asynchronous port using SLIP:
Interface Async 1
encapsulation slip
ip address 193.1.1.1 255.255.255.0
This configuration may need to be enhanced with modifications to default hold queue lengths, buffers, and packet switching mode; we will address these issues in the discussion of PPP.
PPP Communications
PPP is the more modern point-to-point protocol; key features are that it supports the simultaneous running of multiple protocols over one link, synchronous as well as asynchronous communications, dynamic address assignment, and authentication. PPP is a layer 2 (Data Link) protocol; there is, however, a whole link negotiation process that must be completed before two nodes can exchange information at the Data Link level. Let's examine this negotiation process as a set of phases.
The first phase comprises exchange of Link Control Protocol packets. This is like an initial introduction. The two ends agree on the general characteristics of the communication that is about to take place, such as the use of compression or the maximum frame size. An optional phase checks the line quality to see if it can be used to bring up the Network layer protocols. Once the link configuration is agreed upon, an optional authentication process may take place, via either the PAP or CHAP protocol.
The Password Authentication Protocol (PAP) was the first authentication protocol deployed for PPP. To explain the way it works, imagine you have a remote PC using a dial connection to connect to a central router. In this setup, you configure a PAP username and password in the remote PC, which matches a username and password configured in the central router. When the remote PC dials the central router, it will start sending its PAP username and password repeatedly until it either is granted a connection, or the connection is terminated. This is a step up from having no authentication, but is open to a break-in method known as modem playback. Using this method, an intruder hooks into the telephone line, records the modem negotiation transmissions, and plays them back later. By doing this method, the intruder has recorded the username and password for future use.
The Challenge Handshake Authentication Protocol (CHAP) is a stronger authentication process. With CHAP, the remote PC will initiate a connection, negotiate the LCP parameters, and then be met with a "challenge" from the central router. The challenge comes in the form of an encryption key that is unique for every connection made. The remote PC then will use the encryption key to encode its username and password before submitting it to the central router. When the central router receives the encrypted username and password, it will decrypt them using the key sent for that connection and compare them against the valid usernames and passwords for which it is configured. The connection is either authenticated and progresses, or is terminated at this stage.
This method defeats modem playback because the encryption key is different each time; for every connection, it produces a different set of encrypted characters for exchange between remote PC and central router. Within CHAP, there are several different algorithms that may be used for encryption, the most popular being the MD5 algorithm. CHAP's authentication processes typically take place only at link startup time, but the specification allows for this challenge to be issued repeatedly during the lifetime of the connection. Implementation of this feature is up to individual vendors.
Once authentication is complete, the next stage involves defining the particular Network Control Protocols to be encapsulated within PPP. The only choices generally available in popular PC PPP stack implementations are IPCP, for encapsulating IP traffic, and IPXCP for encapsulating IPX traffic; however, a PPP session can support both simultaneously. Each NCP protocol will negotiate the specifics of communication for its Network layer protocol. Once the NCP negotiations are complete, the two endpoints can exchange data at the Data Link (layer 2) level for each of the Network (layer 3) protocols configured. Now that we know what PPP does, let's take a brief look at its frame format, as illustrated in Fig. 6-19.
Figure 6-19: The PPP frame format
This frame contains both useful and redundant fields. The redundant fields are the address and control fields, which always carry the same entries. The address field contains an all-ones byte, the layer 2 broadcast address. (Because PPP only connects two entities together, specific layer 2 addressing is not necessary and individual layer 2 addresses are not assigned.) The control field always contains the binary value 00000011, which defines the type of communication used. The useful fields are the flag, to indicate the start of a frame, the protocol field, which identifies the layer 3 protocol encapsulated in the frame, and the Frame Check Sequence to ensure no errors were introduced into the frame during transmission.
Asynchronous PPP Configurations.     There is much to be said for the configuration of efficient asynchronous communications, some of which can be considered more art than science. We will examine the most common commands and then consider how these commands can be put together in a sample configuration.
The first command, as always when specifying a link layer protocol, is to define the encapsulation for the chosen interface. This is achieved with the following commands:
Router1(config)#interface async 1
Router1(config-int)#encapsulation ppp
If we are specifying PPP encapsulation, this implies that the asynchronous port will be used for a network connection. We therefore should place the port in dedicated mode. The mode choice for an async port is either dedicated or interactive. Placing the port in interactive mode presents the user with a command prompt and allows the user to manually input user name, passwords, and other connection-related information. For security reasons, I prefer to keep the async mode as dedicated, which is achieved with the following command:
Router1(config-int)#async mode dedicated
Next you will want to enable Van Jacobsen header compression. In reality, compressing headers makes comparatively little difference in link bandwidth consumed by the protocol, but with asynchronous communications you should do everything possible to improve throughput. Header compression is turned on by default, but it does not hurt to enable it in case it had been previously disabled. This is achieved in interface configuration mode:
Router1(config-int)#ip tcp header-compression on
The next issue is to assign IP addresses to the ports and to computers connecting to those ports. You have a choice, either to hard-code IP addresses into computers connecting to the async ports, or have the address assigned to the computer when it connects to the async port. If you choose the first option, you must ensure that the IP address assigned to the computer dialing in is in the same subnet as the address range assigned to the async ports themselves.
My preference is to have the IP address assigned to the computer by the async port upon connection. This makes life simpler and does not restrict a computer to being able to dial in to only one location. To have the async interface assign an IP address to a computer when it connects, three separate configurations need to take place. First the async port must be given an unnumbered address. (IP unnumbered is covered more fully in Chap. 7.) Next, the async port must be configured to deliver a specific IP address to the connecting computer. Finally, the connecting computer must have no IP address configured. The two entries in the router port configuration, to define IP unnumbered and 193.1.1.1 as the address assigned to a connecting computer, are as follows:
Router1(config)#interface async1
Router1(config-int)#ip unnumbered ethernet 0
Router1(config-int)#async default ip address 193.1.1.1
Next we discuss Asynchronous Control Character Maps (ACCMs). Flow control between asynchronous devices can either be of the hardware or the software variety. Hardware flow control relies on pin signaling, such as the state of the Data Set Ready (DSR) or Data Terminal Ready (DTR) pins to stop and start transmission. Software flow control uses special characters transmitted between asynchronous devices to stop and start transmission. When relying on characters transmitted between devices to signal modem actions, there is always a danger that strings within the data transmitted will match these special command strings and be inappropriately interpreted by the modems.
An ACCM can be configured to tell the port to ignore specified control characters within the data stream. The value of ACCM that tells an async port to ignore XON/XOFF (software flow control) characters in the data transmitted is A0000 in hexadecimal. This is the default value; if a TCP stack on the computer connecting to the async port does not support ACCM negotiation, however, the port will be forced to use an ACCM of FFFFFFFF. In this case, it is useful to manually set the ACCM with the following command:
Router1(config-int)#ppp accm match 000a0000
Next, we want to enable CHAP authentication on the link. This is done in two stages; first the CHAP user name and password are set in global configuration, then CHAP is enabled on the desired interface. This is achieved through the following commands:
Router1(config)#username chris password lewis
Router1(config)#interface async 1
Router1(config-int)#ppp authentication chap
If an asynchronous router is being used to route traffic from a LAN to a dial-up or other slow link, it can be desirable to slow down the speed at which packets are switched from one interface to another. If packets are switched from an Ethernet port running at 10 Mbps directly to an async port running at 19.2 kbps, the async port can quickly get overwhelmed. By entering the no ip route-cache command as
shown below, the packets are switched at a slower speed. Effectively, this command, entered for each async interface in use, stops the router from caching destination addresses and forces a table lookup every time a packet needs to be routed.
Router1(config-int)#no ip route-cache
One aspect of asynchronous communication that causes endless confusion is the DTE rate configured for a port and its meaning in terms of data throughput on an async line. The receive and transmit DTE rate of async port 1 is set by the following commands, to 38,400 bits per second.
Router1(config)#line 1
Router1(config-line)#rxpseed 38400
Router1(config-line)#txspeed 38400
In asynchronous communications, the DTE rate as defined above dictates the speed at which each packet is sent from the router port to the modem. If the modem can only transfer data across a dial-up link at 14.4 kbps, it will use its flow control procedures to stop more packets from coming out of the router port than it can safely transfer across the link. Thus, over the course of 10 or 20 seconds, the amount of data transferred between the router port and the modem port will not be greater than an average of 14.4 kbps; however, each packet that the router does transmit will be received at a speed of 38.4 kbps from the device sending async characters.
These days most modems employ V.42bis compression, which will allow a modem to sustain effective throughputs that are higher than the modem-to-modem connection rate. V.42 compression is generally quoted at providing up to four times the data throughput that the connection rate would suggest. For example, with four-to-one compression, a 14.4 kbps link will support 57.6 kbps throughput. The effective compression ratio is determined by how compressible the data being transported is. Compressible data includes things such as ASCII text, although binary file transfers are not normally very compressible.
In brief, V.42bis compression looks for common sequences of bits and the modems agree to assign special characters to represent these often-repeated character sequences. By transmitting a special character, the modem may have to transfer only 1 byte of data, rather than the 4 bytes that both modems know it represents. Once a receiving modem receives a special character, it will send out the full associated character string on its DTE port.
Many newcomers to the world of asynchronous communications ask why, even if the DTE rate is set to 115,200 bps, communications across an async link are so slow, often slower than an ISDN link operating at 64 kbps. The answer is that you very rarely get sustained throughput of 115,200 on an async link. While each packet may be transferred between the router and modem at 115,200 bps, the modem flow control will stop the router port from transmitting continuously at that speed.
Chapter 8 gets into troubleshooting serial communication problems in more depth, but two configuration commands that help asynchronous communications are worth considering here. The first is the hold-queue command.
The hold queue of each interface has a specified size, which is the number of packets waiting to be transmitted that it can hold before the interface starts dropping packets. This value can be set for both incoming and outgoing packets. For asynchronous interfaces, it is worthwhile increasing the sizes of both the incoming and outgoing hold queues, which in the following example increases both values to 90.
Router1(config-int)#hold-queue 90 in
Router1(config-int)#hold-queue 90 out
If an interface (Async 1, for example) is exceeding its hold queue limits, an increased number of drops will be seen in the show interface async 1 command. Drops also can increase if the router buffers for given packet sizes are overflowing. The second command we will overview here is the one that sets the number of packet buffers available in the router. To view the state of packet buffer use, enter the show buffers command. The output will show you the number of small, medium, large, very large, and huge buffers used and available, and the number of occasions on which buffers of a type were needed but a packet was dropped because none were available (shown as failures).
A point to note is that packets can be dropped even if the maximum number of buffers has not been exceeded. This phenomenon occurs if several packets of one particular size arrive at the router very quickly and the router cannot create buffers fast enough. If you suspect this may be happening, you can set the number of buffers of a given size to be permanently available. The following is an extract from a router configuration that has had its medium-size buffer allocation altered from the default.
!
buffers medium initial 40
buffers medium min-free 20
buffers medium permanent 50
buffers medium max-free 40
The first entry defines the number of temporary buffers that are to be available after a reload, which is useful for high-traffic environments. The second statement forces the router to try to always have 20 medium buffers free, and if a traffic surge reduces the number of free medium buffers to below 20, the router automatically will try to create more. The third entry defines 60 permanent buffers, which once created are not retrieved by the IOS for reuse of their memory allocation. Finally, the max-free 40 entry ensures that memory is not wasted on unused buffers by returning memory used by more than 40 free medium buffers to the router's general memory pool.
Synchronous PPP Configurations.     If a WAN is being built based on point-to-point links between router serial ports, the popular choices for the link-level encapsulation are the default Cisco version of HDLC and PPP operating in synchronous mode. PPP is a more modern protocol and offers better link-level authentication than Cisco's HDLC, but there is one compelling reason to build your network based on the Cisco HDLC. Consider Fig. 6-20.
Figure 6-20: Router serial interfaces connected via CSU/DSU devices
Suppose the line protocol on the connected Serial 0 ports will not come up, but everything looks good with the interface configurations, so you want to test the line connecting the two CSU/DSU devices. A good way to start troubleshooting this situation is to first put CSU/DSU 1 in loopback and see if the line protocol on the Serial 0 interface of router 1 comes up, as shown by the show interface serial 0 command. If this is okay, take CSU/DSU 1 out of loopback and put CSU/DSU 2 in loopback, then see if the Serial 0 interface comes up as a result. This is a simple yet powerful technique for locating a problem in a communication system, and works well if the encapsulation for both Serial 0 interfaces is set to default Cisco HDLC. With PPP encapsulation, an interface protocol will not reach an up state when connected to a CSU/DSU in loopback; you therefore do not have this type of troubleshooting as an option.
A situation in which you really do need to use synchronous PPP is one in which you decide to use the Cisco 1000 LAN Extender product. This product line was designed to link remote offices to a central location at low cost and with low maintenance. These LAN extenders are not real routers; they are layer 2 bridge devices. Figure 6-21 illustrates a typical configuration for a low-cost remote location installation. We will take some time now to explore configuring one of these devices.
In this configuration, the Cisco 1001 has two interfaces connected, a V.35 connector to the CSU/DSU and an Ethernet connection to the local PC. There is no configuration in the 1001; all configuration is kept in the central router, which makes installation and remote support of this device simple enough that even nontechnical staff can connect the device as needed. There are two parts to the configuration of the central router interface, one for the router 1 serial interface and one for the virtual LAN extender, which is configured as a LEX interface on router 1. The Serial 0 interface configuration for router 1 in Fig. 6-21 is given as follows:
!
interface serial 0
no ip address
encapsulation ppp
!
The configuration for the LEX port that also exists on router 1 is as follows:
!
interface lex 0
ip address 195.1.1.1 255.255.255.0
lex burned-in-address 0000.0c32.8165
!
Figure 6-21: LAN extender network connections
The lex burned-in-address is the MAC address of the Cisco 1001 being installed. When a LAN extender is installed, all the workstations connected to it are given addresses on the same subnet as the LEX port. With the configuration above, the PC in Fig. 6-21 would be addressed 195.1.1.2, while subsequent PCs connected to the 1001 device LAN would have addresses 195.1.1.3, 195.1.1.4, and so forth.
As you can see, all configuration that makes the connection unique is under the LEX configuration. This means that you can connect a remote LAN extender to any serial port that has no IP address and PPP encapsulation configuration. When a LEX first connects to the central router, it will try to bind to whatever port to which it is connected. To see the status of a LEX connection, issue the command show interface LEX 0, which will tell you what port the LEX is bound to, the LEX MAC address, its IP address, and the Ethernet encapsulation type. Once you know to what port the LEX is bound, you can use the show interface serial 0 command (assuming the LEX is bound to Serial 0) to see the number of interface resets, carrier transitions, and CSU/DSU signals.
The price to pay for this relatively cheap and simple way of connecting remote devices is in the area of advanced troubleshooting information. To report problems, the LEX relies upon a set of front panel lights. Under normal conditions, these lights flicker to indicate traffic passing over the link. During error conditions, the lights blink solidly a number of times. The number of times the lights blink indicates the nature of the problem. It can be a challenge to get nontechnical users to notice the difference between a flicker and a solid blink and to correctly count the number of blinks generated by the LEX. The errors reported by the front panel lights are as follows:
One blink
The serial link is down.
Two blinks
No clock received from CSU/DSU.
Three blinks
Excessive CRC errors on the line.
Four blinks
Noisy line.
Five blinks
CSU/DSU in loopback.
Six blinks
PPP link negotiation failed.
SDLC
Many of the protocols we have discussed are based on the High-level Data Link Control protocol (HDLC) format, which is related to IBM's Synchronous Data Link Control (SDLC). It is worth briefly looking at how these protocols work and at their interrelationships.
SDLC was designed for serial link communications in SNA networks in the 1970s and is in use for that purpose today. SDLC is a bit-oriented protocol; previously, protocols like IBM's BiSync and DEC's DDCMP were byte-oriented. Bit-oriented protocols offer more flexibility, are more efficient, and have now completely replaced byte-oriented protocols for new product development. Once IBM had written SDLC, it was used as a basis for further development by several standards bodies to produce SDLC variants, which are listed as follows:
  The ISO based its development of the HDLC protocol on SDLC.
  LAPB was created by the CCITT (now called the ITU, the International Telecommunications Union), which used HDLC as its starting point.
  The IEEE 802.2 used HDLC as a base for developing its link-level protocols for the LAN environment.
It is worth noting that the IBM QLLC protocol can be implemented at the Data Link layer when transporting SNA data over X.25 networks. In this scenario, QLLC and X.25 replace SDLC in the SNA protocol stack.
An IBM protocol, SDLC is geared toward everything being controlled by a central processor. SDLC defines a primary end and a secondary end for communications, with the primary end establishing and clearing links and polling the secondary ends to see if they want to communicate with the primary. An SDLC primary can communicate with one or more secondary devices via a point-to-point, multipoint (star), or loop (ring) topology. The SDLC frame format is shown in Fig. 6-22. The HDLC, LAPB, and 802.2 variants of SDLC do not define primary and secondary devices in communication.
Figure 6-22: SDLC frame format
SDLC frames are either Information frames for carrying user data and higher layer protocol information, Supervisory for status reporting, or Unnumbered for initializing an SDLC secondary.
HDLC is closely related to SDLC, but instead of one transfer mode, HDLC supports three. HDLC's Normal Response Mode is how SDLC operates, wherein a secondary cannot communicate until the primary gives it permission. The HDLC Asynchronous Response Mode allows a secondary to initiate communication, which is the method used by the X.25 LAP protocol. HDLC also supports Asynchronous Balanced Mode, which is used by the X.25 LAPB protocol and allows any node to communicate with any other without permission from a primary.
LAPB operates only in Asynchronous Balanced Mode, allowing either the DTE or DCE device to initiate calls. The device that initiates calls becomes the primary for the duration of that call.
The IEEE 802.2 committee split the ISO Data Link layer in two, the upper half of which is the Logical Link Control (LLC) sublayer, and the lower half being the Media Access Control (MAC) sublayer. The 802.2 LLC layer interfaces with layer 3 protocols via Service Access Points (SAPs) and different LAN media, such as 802.3 and 802.5 implemented at the MAC layer. IEEE 802.2 has a similar frame format to SDLC.
ISDN
ISDN stands for Integrated Services Digital Network; it is a synchronous dial-up service offered by most local telephone companies these days. Unlike many of the other networking technologies we have examined, ISDN is not a packet-switching technology; rather, it is a circuit-switched technology, similar to the plain old telephone service (POTS). My recommendation when implementing ISDN for a single PC is to not use one of the devices that connect to the serial COMx port on a PC. They may be easy to set up, but you will not get the full benefits of ISDN communications. These devices have to use asynchronous communications to exchange data with the PC serial port. You will get better performance if you connect ISDN synchronously all the way to your PC, as the serial port circuitry is not as efficient as a LAN card at getting data on and off your PC's bus.
Cisco offers a standard solution for this with the 1000-series LAN extenders. The 1004 LAN extender will take an ISDN BRI circuit in one side and an RJ-45 connector for Ethernet connectivity in the other side. If you then use a crossover RJ-45 cable, a twisted-pair Ethernet card in the PC can be connected directly to the Cisco 1004. This is shown in Fig. 6-23. In fact, the configuration shown in Fig. 6-23 could support an additional 22 remote PCs establishing ISDN connections simultaneously through ISDN to the one PRI connection.
Figure 6-23: Communicating synchronously from a remote PC to a router via ISDN
ISDN Terminology.     With ISDN there is a slew of new terms that might seem daunting at first; in reality they are quite simple, so let's define them first.
Basic Rate ISDN (BRI).     A BRI consists of two B channels and one D channel. The B channels each have 64 kbps capacity, with the D channel being used for call signaling and having 16 kbps capacity. The two B (known as bearer) channels can be used for voice or data, and can be combined to provide 128 kbps throughput. BRI access is via the same copper telephone lines that now provide regular telephone service to homes. The attraction of this technology for telephone companies is that it allows higher-speed services to be delivered using the existing cabling. In many locations, however, the existing copper has had to be upgraded to support the encoding necessary to transmit this amount of data over a line.
Primary Rate ISDN (PRI).    PRI services are delivered by a T-1 circuit (1.544 Mbps) in the United States and an E-1 (2.048 Mbps) in Europe. In the United States, a T-1 delivering PRI is split into 24 channels of 64 kbps, one of which is used as the D channel for signaling, leaving 23 for voice, data, or bonding together to form a connection of higher than 64 kbps. When a T-1 circuit provides channelized service, 8 kbps is lost to the channelization process, giving an available bandwidth of 1.536 kbps. A typical application for PRI would be to provide 23 central dial ports for remote branches to dial into on an as-needed basis. A PRI can be terminated in an RJ-45 type connector, which can be directly connected to a Cisco router device such as an AS-5200, or a PRI interface on a 7000-series router. This means that you can provide 23 dial connections on one physical interface without having to worry about individual modems and cabling.
Link Access Protocol D Channel.     LAPD is a derivative of X.25's LAPB protocol and is used by the ISDN equipment at your site to communicate with the telephone company's central office switch all the while the connection is active.
Terminal Endpoint Identifier.     TEI is a unique identifier for each of the up to eight devices that can hang off of an ISDN connection. Typically the TEI will be configured by the network via D channel exchanges, but it may be necessary to configure these identifiers by hand.
Q.931.     The D channel uses control messages that conform to the ITU Q.931 specification to establish, terminate, and report on status of B channel connections. It is worth confirming that these control signals pass through a separate D channel (termed out-of-band); if a separate D channel network is not available, an extra 8 kbps is taken out of each B channel, leaving only 56 kbps available for data transmission.
SAPI.     Frame relay or X.25 frames as well as control messages can traverse the D channel. It is the Service Access Point Identifier field in the LAPD frame that identifies which type of traffic is using the link.
SPIDs and DNs.     A SAPI/TEI pair identifies a particular device on a given ISDN link, but has only local significance. For a call to traverse an ISDN network, network-wide parameters need to be defined. In concept, a SAPI/TEI pair are the same as an LCN in an X.25 network, in that the LCN is significant between a DTE and DCE, but an NUA is necessary to route traffic across an X.25 network. To establish an ISDN connection, you need a directory number (DN), which looks identical to a regular telephone number. With a DN, you know what number to use to call another ISDN user. That is not enough, however. We know that an ISDN connection may have many different types of devices attached, so to inform the ISDN switch in the telephone company's network what you have at your location, the telephone company will assign you one or more service profile IDs (SPIDs) that identify the equipment you are using on your ISDN connection.
Switch Types.     You must know the Central Office switch type used by your ISDN provider and configure that in the device connecting to the ISDN circuit. In the United States, the switch type might be AT&T 5ess and 4ess, or Northern Telecom MS-100; in the United Kingdom, it might be Net3 and Net5; and in Germany, it is 1TR6.
Network Termination 1 (NT1).     An NT1 is a device that converts ISDN digital line communications to the type used by the BRI interface. Outside of the United States, this is typically supplied by the telephone company, but inside the United States, subscribers generally have to supply their own NT1. In effect, it is the circuitry that interfaces your ISDN connection to the ISDN local loop network.
Terminal Endpoint Devices (TE1 and TE2).     A TE1 is a native ISDN interface on a piece of communications equipment, such as a BRI interface on a Cisco router. A TE2 device is one that requires a Terminal Adapter (TA) to generate BRI signals for it. The TA converts RS-232 or V.35 signals in to BRI signals. A Cisco router serial interface needs to be connected to an NT1 via a TA device.
Let's see how a typical ISDN call is established by referring to Fig. 6-24, which shows how a TE1 is directly connected to the NT1 device, whereas a TE2 needs a TA device to connect to the ISDN network. Imagine we want to call a digital telephone that has an ISDN phone number of 123-4567. To do this, the originating equipment connects to the telephone company's Central Office switch. The CO switch knows what type of device the originating equipment is through its associated SPID. Next, the number 123-4567 is passed to the switch as the destination. The CO switch will then locate via SPID an appropriate device at the destination number that can accept the call. A D channel conversation takes place and a B channel is allocated from source to destination to transport data between the two ISDN devices.
Configuring ISDN BRI Services.     ISDN connections generally are configured as a type of Dial on Demand Routing (DDR). This provides for a dial backup service to a leased line link, a dial connection for occasional
Figure 6-24: ISDN device interconnections
Internet access, or a remote site dialing a central location for occasional server access.
The first example is for a Cisco 2501 that has its Serial 0 interface attached to a leased line connected to a central site. The Serial 1 port is connected to a Terminal Adapter device that dials back to the central site if the primary leased line on Serial 0 fails. In this application, some of the configuration commands need to be entered into the Terminal Adapter and some into the router.
For the Terminal Adapter configuration, we need to identify the ISDN provider's switch type, the number to dial, and the SPID assigned for the connection. In the router, we need to identify what will cause a dial connection to be made. Typically for this type of application, the router serial port connected to the Terminal Adapter will raise the DTR signal when a connection is needed; the TA will sense this and, having all the information necessary to make the desired connection, will initiate a call. This is the relevant configuration for the Serial 0 and Serial 1 ports:
interface serial 0
backup delay 10 45
backup interface serial 1
!
interface serial 1
ip unnumbered serial 0
The command backup delay 10 45 for Serial 0 configures the router to attempt to establish a backup connection if the primary connection loses a carrier signal for more than 10 seconds, and will maintain that backup connection until the primary carrier signal has been constantly up for at least 45 seconds.
The command backup serial interface 1 tells the router that Serial 1 is to be used as the backup interface. This command sets DTR low until the port is activated to establish a connection.
The only necessary command for the Serial 1 port is the one giving it an IP address, which in this case is an unnumbered IP address, linked to the address of Serial 0. (IP unnumbered will be covered in Chap. 7.) There typically will be an ISDN circuit ready at the central site to receive this call. Full connectivity is restored to the remote location when the ISDN circuit is established and the routing table on the central site router has adjusted so that it knows to get to the remote router via a new interface. (The routing protocol implemented, such as IGRP, will make these adjustments for you.)
The second example is for a router that has a BRI port and therefore does not need a TA device. The goal is to provide connectivity to a set of centrally located servers on an as-needed basis. The access needed from this router to the servers is sporadic, so the ISDN solution is implemented because a leased line connection is not cost-justified. This setup is illustrated in Fig. 6-25, along with pertinent extracts from the router configurations.
Figure 6-25: A dial-on-demand routing solution using a router BRI interface
In this application, the ISDN link is made only when there is traffic that the DDR interface on router 1 deems "interesting." We have to tell the router what traffic is worth establishing a link for. For example, you probably will not want the ISDN link to be brought up every time a router wants to send a regular broadcast IGRP update. These types of links are usually set up with static routes to reduce ISDN utilization. You would therefore not enable a routing protocol process on router 1. The process to define a link can be summarized as follows:
  Configure global ISDN parameters.
  Identify the packet types that will initiate an ISDN connection.
  Define and configure the interface over which these identified packets will be sent out.
  Set the call parameters to be used for establishing the DDR link, such as the number to call.
The configurations illustrated in Fig. 6-25 are similar enough for the remote and central router BRI ports that we will explain only the remote router BRI port configuration in detail.
Global command isdn switch-type basic-dms100 defines the switch type used by the ISDN provider company.
Global command dialer-list 5 protocol ip permit is paired with the dialer-group 5 interface command. The dialer-list command here states that IP packets destined for, or routed through, the interface tagged as belonging to dialer-group 5 are "interesting" and will trigger a DDR connection. More complex permissions can be defined by the use of access lists. In order to use an access list, one must be defined in global configuration. If access list 101 is created, this access list can then be associated with a dial list with the following dialer-list 5 list 101. Appropriately specifying access list 101 will allow you to define specific IP addresses or protocols (such as Telnet or FTP) that may or may not cause a DDR connection to be made.
The commands encapsulation ppp, ip address, and ip route are as explained elsewhere.
Command dialer-group 5 identifies the BRI 0 interface as belonging to this group, essentially marking BRI 0 as the port that will respond to the interesting packets defined by dialer-list 5.
Command isdn spid1 0987654321 sets the SPID number for this ISDN connection as supplied by the ISDN connection provider.
Command dialer idle-timeout 200 specifies that if there is no traffic on the connection for 200 seconds, the link will be dropped.
Command dialer map ip 164.3.8.2 name router2 1234567 maps the telephone number 1234567 to the IP address 164.8.3.2. If router 1 wants to send a packet to the 164.3.6.0 subnet, its routing table will identify 164.3.8.2 as the address to which to forward the packet, setting off a DDR connection and causing router 1 to dial 1234567. This command can be modified if you know that the number you are dialing is a 56 kbps rather than 64 kbps ISDN connection. In this case, the command would be dialer map ip 164.3.8.2 name router2 speed 56 1234567. If we want to make router 2 a receive-only connection, we can input this command with no phone number argument. It is required to give the hostname of the router being called in this command, which must be the same as that defined in the username command (in this case, router 2).
Command ppp authentication chap identifies that CHAP authentication will be enforced prior to the granting of a connection.
Command username router2 password aaa generically identifies a username and password pair that is authenticated to connect to this router. If a workstation were connecting, it would have to use "router 2" and "aaa" to successfully negotiate CHAP. We now, however, have two routers that are connecting together and negotiating authentication. The username that each router will use is its hostname, and the password that it will use is the password set in this command. What all this means is that the username on router 1 must be the same as the hostname of router 2, and that both routers must have the same password set.
Command ip route 164.3.6.0 255.255.255.0 164.3.8.2 defines a static route in the routing table that identifies that the BRI interface on router 2 is the next hop for subnet 164.3.6.0.
The third example is a user who wants to establish an ISDN connection from home to a central site when a network resource located at a central site is required. This type of requirement is well-suited to the Cisco 1004 configuration illustrated in Fig. 6-23. The 1004 is used in the United States because it has a built-in NT1, whereas the 1003 does not have an NT1 and is used elsewhere in the world; the NT1 in that case is usually supplied by the ISDN provider. The Cisco 1004 is very different from the 1001 discussed earlier. The 1004 has a PCMCIA slot for a memory card that holds the configuration. The 1004 is a router, running the full Cisco IOS, whereas the 1001 is a bridge.
The configuration for a 1004 is therefore the same as the remote router in the second example discussed above. A 1004 memory card can be configured at a central location and sent out to a remote site for a nontechnical person to insert in the PCMCIA slot.
Configuring ISDN PRI Services.     In this section we will discuss how a PRI could be configured for multiple sites to dial into. A PRI is effectively 23 B channels and one D channel, each with 64 kbps bandwidth, all on one physical link. When setting up a central location with many interfaces available, it is more efficient to set up the interfaces so that a remote site can dial into any interface. This gives you more efficient use of the interfaces and you do not have to dedicate any to particular sites. Working on the theory that not all remote sites are connected at the same time, setting up the PRI to allow any site to dial any interface allows you to set up fewer interfaces than there are remote sites, yet provide service to all locations as they need it.
There are two methods for allowing remote sites to dial into any interface in a pool. With the first, the remote site gets its address from the interface it dials into at connection time. In the second method, the PRI is configured as some type of rotary group and has dynamic routing enabled so that all interfaces act as one pool of interfaces. The first option is best suited to single workstations dialing in, typically on asynchronous communications. The reason for this is that a single workstation does not need an IP address when it is operating in a standalone mode, and gets one when it needs one for networking. The second option is better suited for providing central backup for remote LANs. IP addresses will be assigned to the workstations on these LANs prior to establishment of the backup link, so some type of dynamic routing is necessary for the rotary to operate effectively.
Now we will examine the second option. There are some additional steps involved in setting up a PRI that are not necessary when setting up a BRI. A PRI is delivered on a T-1 in the United States and Japan, and on an E-1 elsewhere in the world. The settings shown here are for a T-1 circuit. To connect to a PRI, you need a CT1 Network processor Module for the 4x00-series router, or a Multichannel Interface Processor for the 7x00-series router. Let's assume we are using a 4700 router for the commands that follow.
Figure 6-26: PRI configuration for remote routers to connect to via ISDN
Figure 6-26 illustrates a typical configuration for setting up a PRI to act as a rotary pool of interfaces for incoming connections that already have a configured IP address. The figure shows only one remote site (router1), but the configuration presented should support 50 or more remote sites occasionally dialing in. The key difference between the setup for a single dial connection and this multiconnection setup is that the username/password pair for each remote router must be configured on the central 4700. In addition, a dialer map statement must be present in the 4700 dialer1 interface section for each remote router. On subsequent versions of the Cisco IOS, dialer map statements are not necessary, and the router uses Inverse ARP in the same manner as it does in a frame relay network to map IP addresses to router names and telephone numbers. Let's examine each command in this configuration.
  Command isdn switch-type dms-100 defines the switch type used by the telephone company as a Northern Telecom DMS-100.
  Command username router1 password aaa defines the valid username and password pairs for all remote routers dialing in.
  Command controller t1 0 sets the necessary configuration for the T1 controller card in the 4700 slot 0.
  Command framing esf configures the T-1 controller slot 0 as the Extended Super Frame frame type, which is that used in the United States.
  Command linecode b8zs defines the line-code type as Binary 8 with Zero Substitute. This is the value required for T-1 PRIs in the United States.
Command interface dialer1 is there to avoid having to enter the same thing into the router configuration multiple times. (There is no physical dialer interface.) This command enables you to specify a configuration that can be applied to multiple interfaces. To give a physical interface the configuration that is specified in the interface dialer section (in this case, dialer 1), put a single command in the physical interface to make it a member of the specific rotary group (in this case, dialer rotary group 1).
Command ip unnumbered Ethernet0 is covered more fully in Chap. 7, but in this instance it lets the dialer 1 interface "borrow" an IP address from the Ethernet port. The BRI port at the remote end also will have an IP unnumbered configuration. IP unnumbered enables point-to-point connections to route packets between the networks at each end of the link, without dedicating a specific subnet number to the point-to-point link. Without this feature, it would not be possible to pool the central PRI connections. If each PRI channel had its own subnet, it could only directly communicate with other IP devices on that same subnet.
The remaining commands of interest are as follows:
  Command encapsulation ppp sets the encapsulation to PPP.
  Command no ip route-cache slows the speed of packets switched from a fast to a slow link.
  Command dialer idle-timeout 300 drops the connection after an idle time of 300 seconds.
  Command dialer-group 1 identifies the traffic that is to pass over the link as specified in the dialer list command.
  Command ppp authentication chap was discussed in the previous section on BRI.
  Command dialer map ip 164.8.4.1 name router1 was discussed in the previous section.
  Command dialer list 1 protocol ip permit was discussed in the previous section.
  Command interface serial 0:23 identifies the 24th channel, the D channel, because the channel numbers start at zero. The commands in this section configure all the B channel interface parameters.
  Command dialer rotary-group 1 applies all the configuration commands specified in the interface dialer 1 section to the B channels.
Simple ISDN Monitoring.     There are two basic commands for viewing the status of ISDN BRI connections: the show controller bri and show interface bri commands.
Command show controller bri displays status regarding the physical connection of the ISDN D and B channels. The most useful part of this display is that it states for each B and D channel whether the layer 1 (Physical layer) connection is activated. This is useful when performing remote diagnostics. If you can Telnet to the router, this command will tell you if a functioning ISDN line has been connected to the BRI port. The equivalent command for a PRI connection is the show controller t1 command.
Command show interface bri0 1 2 shows the connection status of the two B channels. If the numbers 1 and 2 are omitted, this command displays D channel information. The sort of information
this command display gives you includes whether the PPP protocols such as LCP and IPCP successfully negotiated, the input and output data rate, the number of packets dropped, and the state of the hold queues.
Miscellaneous ISDN.     There are a few ISDN commands that may prove useful in special situations and they are presented here in no particular order.
Use command isdn caller 212654xxxx if you want to accept calls only from a specified number. The format shown here is useful if you know that calls may be originating from several extensions in the one location. The calls accepted start with 212654, but may have any value for the last four digits. If you want to accept calls from only one number, you may specify the whole number, also. Care should be taken with this command, because if the ISDN switch to which you are connected does not support this feature, using this command will block all incoming calls.
Command isdn not-end-to-end 56 sets the line speed for incoming calls to 56 kbps. This is useful if you know that the originating caller has a 56 kbps connection, but your receiver has a 64 kbps connection. If calls originate at one speed and are delivered at another, problems could occur with data corruption.
Command dialer in-band, if applied to an asynchronous interface, means that modem chat scripts will be used. If applied to a synchronous interface, it means that V.25bis commands will be used. Basically, this command configures the interface to use the bearer (B) channel for call setup and teardown on an ISDN connection, rather than the usual D channel.
Command dialer load-threshold 191 configures the interface to start using the second B channel when the first has reached, in this case, 75 percent capacity. The figure 191 is 75 percent of 255; the valid numerical range for this command is 1-255.
Command dialer string 1234567 is a simpler command to use than the dialer map command if the interface being configured is going to dial only one location. Essentially this command specifies the number that will be dialed whenever a connection is initiated.
Command BACKUP LOAD X Y can be used for router setups where a dialer group is not defined and you want to have an ISDN connection established to add bandwidth to a link that is getting congested. The example shown below configures a secondary line to activate (in physical terms this means that the serial interface will raise the DTR signal) once the traffic threshold on the primary interface exceeds 80%. Additionally, when the combined bandwidth utilization of the primary plus secondary falls to below 50% of the primary link's bandwidth, the secondary link will disconnect the ISDN connection.
Interface serial 0
Backup interface serial 1
Backup load 80 50
Of course, this assumes that an external ISDN terminal adapter is used to connect the router serial interface to the ISDN line and that the terminal adapter is configured to dial on DTR and has all the necessary information to dial (destination number, switch type, etc).

 


 
Books24x7.com, Inc © 2000 –  Feedback